Distributed computing has become commonplace in today's highly interconnected and networked environments. As a result, software services interface with one another via local network connections and external network connections. Generally, a local network connection exists if both a local service and a remote service are communicating within a secure environment (e.g., within a firewall, a virtual private network (VPN), a local area network (LAN), a wide array network (WAN), and the like). Similarly, an external network connection exists if the local service and the remote service are communicating within a less secure environment (e.g., outside a firewall, an Internet connection, and the like).
In today's ever-mobile society, organizations/service providers have gone to great lengths to ensure that their employees/customers have access to resources of the organizations/service providers at any time and any location. As a result, high-availability (HA) and remote access to software services is a top priority, since employees/customers are more likely to use the software services, if the time and place associated with any particular access are not restricted.
However, creating software services that can seamlessly communicate with one another through a local network connection and simultaneously through an external network connection remains problematic. This is so, because a local service requires a local address to establish a local network connection with a remote service and a different external address to establish an external network connection with the remote service. Moreover, as increased numbers of local services attempt to access remote services, the remote services must be replicated on multiple servers in order to handle additional processing associated with the additional local services. Each remote service replication is represented by a different address that must be used by an appropriate local service when attempting to connect with the remote service.
Furthermore, often the remote services will be moved or upgraded from one server to another server, and each move or upgrade results in address changes associated with the remote services. The address changes must be communicated to any affected local services. Generally, the address changes are manually administered, such as when a network administrator manually visits each client within a network having an affected local service and installs the changed address for a moved or upgraded remote service. This process is time and resource intensive, and therefore it is not desirable.
Alternatively, address changes can be communicated to an end user associated with an affected local service, and the end user can be relied upon to make the appropriate address changes for moved or upgraded remote services. Yet, this technique often creates more work for network administrators or network support groups, since often the end user is not adept enough to make the appropriate address changes for the remote services without requiring some phone/electronic mail (email) assistance from the network administrators or the network support groups. And, as one of ordinary skill in the art readily appreciates, even minimal address changes can create an untoward volume of phone calls/emails from confused and frustrated end users.
Moreover, conventional interactions between local services and remote services do not automatically distinguish or detect whether a particular connection type is a local network connection or a remote network connection. As a result, when connection types change, a local service will be unable to successful connect with a remote service until a manual address change is communicated to the local service. This can be especially frustrating for an end user.
For example, consider an end user having a local email service that connects and interfaces to a remote email service, where the remote email service manages the end user's email account. The local email service resides on a laptop computing device, that when docked interfaces with the remote email service via a local network connection (e.g., LAN within a firewall) using a local address for the remote email service. If the end user takes the laptop out of the docking station and attempts to connect with the remote email service through a standard Internet connection (e.g., outside the firewall), then the local email service will require the end user to manually change the local address for the remote email service to a remote address. Further, many first-time end users will not be aware of the needed address change, correspondingly these first-time end users will frantically attempt to get phone support to resolve the problem. Additionally, even experienced end users will be surprised when a previously used external remote address fails, because of a moved or upgraded server, which was not communicated to the end users.
Additionally, as a local service attempts to use a connection address to establish a connection with a remote service, if the used address is incorrect, then the end user is forced to endure a latency period of time while the local service waits for a time out communication indicated that the used address is not acceptable. Once the latency period of time lapses, the end user is finally informed that the address attempted was incorrect. Again, this is frustrating and time consuming for the end user, and even experienced end users will forget to change addresses, and correspondingly will be forced to endure this undesirable startup latency period of time before being able to connect with a desired remote service.
As is apparent, there exists a need for improved techniques that can automatically connect local services with remote services, irrespective of whether the local service is using a local network connection or an external network connection. Furthermore, there exists a need for techniques that better predict correct addresses for remote services, such that unwanted and undesirable startup latencies, associated with connecting local services to remote services, are minimized.